Hmm, shouldn't this be a TypeError here then?

doesn't raise a TypeError, i.e. it succeeds but this is raise so succeeding means throwing an exception

Oops, somehow completely blinded the "doesn't" part. Maybe the description would be better as "raises RuntimeError".

It was written to contrast the test above it:

it "raises a TypeError when given cause is not an instance of Exception" do
  -> { raise "message", cause: Object.new }.should raise_error(TypeError, "exception object expected")
end

it "doesn't raise a TypeError when given cause is nil" do
  -> { raise "message", cause: nil }.should raise_error(RuntimeError, "message")
end

We're testing (speccing?) the different types that can be given as the cause argument. An object that is not nil and not an Exception is not allowed, so the cause argument causes the exception.
In the second test, we're passing a nil as cause argument, this is accepted and ignored, and now the raised exception is what we explicitly do with raise.

So both cases throw an exception, but it's for very different reasons, and the second one is the happy path.

Maybe something like "it accepts nil as a value for cause is accepted and ignored" would be a better description. And to put the icing on the cake, we should probably add a block to raise_error and verify e.cause.should be_nil

A describe "the cause: argument" do would also help clarity & structure, and make it clearer those examples are related.

Considering it's me who was confused, I will make a PR for this soon™